Recently, with substantial development of network systems, multimedia data is more often transmitted to a plurality of receiving apparatuses belonging to the same group in, for example, television conference or network games. In this case, multicast communication is known as a communication method for effectively transmitting the same packet to all receiving apparatuses.
A transmitting apparatus classifies receiving apparatuses to which multimedia data is delivered, into small groups of about ten people, and carries out multicast communication on a per small group basis. Multicast communication schemes include the explicit multicast scheme. These schemes refer to storing destination addresses of all receiving apparatuses belonging to a group in an option header or payload of a packet as a receiver list and explicitly specifying all receiving apparatuses to which a packet is delivered, at a transmitting apparatus. Hereinafter, what is simply referred to as a “packet” in this description refers to a packet according to the explicit multicast scheme.
There is “explicit multicast” (hereinafter “XCAST”) as a typical explicit multicast scheme (see Non-Patent Document 1).
A packet distribution method according to the explicit multicast scheme will be described in detail.
When receiving a packet, a router supporting the explicit multicast scheme searches a unicast route list that the router has for all destination addresses stored in the option header or payload of the packet and check the transmission interface matching each destination address. Further, when the packet needs to be outputted to a plurality of output interfaces, the router duplicates packets equaling the number of transmission interfaces. At this time, the router deletes destination addresses other than destination addresses of receiving apparatuses included in the transmission interfaces from the option header of a packet or adds a mark showing that delivery is completed. Further, the router rewrites the destination addresses written in the IF header to the addresses of receiving apparatuses to which a packet is not yet delivered.
On the other hand, the router that does not support the explicit multicast scheme searches the unicast route list from the destination address written in the IP header without referring to the destination addresses stored in the packet. Then, similar to normal unicast communication, the router transmits the packet. That is, the router that does not support the explicit multicast scheme does not carry out multicast communication. However, when a receiving apparatus that supports the explicit multicast scheme receives this packet, the apparatus refers to the receiver list stored in the option header. Further, when the receiver list includes destination addresses to which the packet is not yet delivered, the receiving apparatus duplicates packets, rewrites the destination addresses of the IF header to destination addresses to which the packet is not yet delivered, and transmits the packet.
According to the above method, in the explicit multicast scheme, even if all routers on the route do not support the explicit multicast scheme, the packet could be delivered to all receiving apparatuses.
FIG. 9(a) illustrates this operation.
In FIG. 9(a), when transmitting a packet to receiving apparatuses 902 to 904, transmitting apparatus 901 writes the delivery order from receiving apparatuses 902 to 904 as is in the receiver list and stores this the option header.
Here, if receiving apparatuses 902 and 904 are in Japan and receiving apparatus 903 is in the United States of America, a packet is transmitted from receiving apparatus 902 in Japan to receiving apparatus 903 in the U.S. and from receiving apparatus 903 in the U.S. to receiving apparatus 904 in Japan.
In this way, depending on the delivery order of destination addresses in the receiver list, there is a problem that inefficient delivery is carried out.
To solve this problem, there is a technique as disclosed in Patent Document 1. That is, this technique refers to, in the explicit multicast scheme, rearranging the receiver list to transmit a packet arranged in ascending order of addresses of receiving apparatuses, to descending order. In this way, receiving apparatuses with similar addresses are adjacent in the receiver list, so that it is supposed to be possible to avoid a round-trip of a packet between two points which are geographically distant apart. For example, in FIG. 9(b), addresses are assigned to receiving apparatuses 902 and 904 from the same address domain and an address is assigned to the receiving apparatus in the U.S. from another address domain. For this reason, if transmitting apparatus 901 writes the addresses of the receiving apparatuses in order of addresses, receiving apparatus 904 is listed next to receiving apparatus 902, so that it is supposed to be possible to avoid a round-trip of a packet between Japan and the U.S.
However, when multimedia data is transmitted by the explicit multicast scheme, if network congestion occurs, a receiving apparatus is not able to receive multimedia data stably, and so quality of images and speech significantly deteriorates. For this reason, it is important to avoid congestion. However, in the explicit multicast scheme, transmission rate control is not defined, and so, even if congestion occurs, it is not possible to avoid congestion by controlling a transmission rate.
TFRC (TCP Friendly Rate Control) that uses feedback information is known as the transmission rate controlling method (see Non-Patent Document 2). This “TFRC” refers to increasing the transmission rate until packet loss occurs and decreasing the transmission rate when packet loss occurs. By this means, the receiving apparatus is able to carry out transmission at a suitable transmission rate.
Then, transmission rate control applying TFRC to communication that employs the explicit multicast scheme is studied, and SICC (Sender Initiated Congestion Control) is proposed (see Non-Patent Document 3).
FIG. 11 is a packet delivery diagram showing operation of SICC.
In FIG. 11, a transmitting apparatus sets in advance a plurality of classes to which different transmission rates are assigned. According to SICC, upper limit B (bps) of the transmission rate is set and three classes that include ½ class and ¼ class are provided by lowering by ½ than upper limit B. The transmitting apparatus classifies receiving apparatuses into classes and transmits on a per class basis a packet that stores in the header the destination addresses of receiving apparatuses belonging to each class.
To which class a receiving apparatus belongs is determined by an available band for each receiving apparatus. That is, according to the TFRC requirement, the transmitting apparatus receives information, fed back from each receiving apparatus to the transmitting apparatus, including the loss event rate, the time the received packet is transmitted, from the transmitting apparatus and the band in which the receiving apparatus is able to receive the packet, and estimates the available band for each receiving apparatus based on these items of feedback information. Then, based on the estimated available bands for receiving apparatuses, the transmitting apparatus classifies receiving apparatuses into classes in which transmission rates are set such that the available band can be utilized at maximum.
Further, similar to TFRC, the processing of classifying receiving apparatuses into classes is carried out by the transmitting apparatus each time feedback information is received from receiving apparatuses, so that it is possible to dynamically classify receiving apparatuses into classes suitable for available bands according to network conditions. In this way, each receiving apparatus is classified into either one of classes and the transmitting apparatus transmits a packet on a per class basis, so that it is possible to realize transmission rate control matching the network condition of each receiving apparatus.    Patent Document 1: Japanese Patent Application Laid-Open No. 2004-120222    Non-Patent Document 1: Y. Imai, M. Shin and Y. Kim, “XCAST6: eXplict Multicast on IPv6,” IEEE/IPSJ SAINT2003 Workshop 4, IPv6 and Applications, Orland, January, 2003.    Non-Patent Document 2: M. Handley et al., “TCP Friendly Rate Control (TFRC): Protocol Specification,” RFC 3448, Internet <URL: http://www.faqs.org/rfcs/rfc3448.html>    Non-Patent Document 3: “Proposal for Congestion Control Method on Sender Initiated Multicast,” Eiichi Muramoto, Takahiro Yoneda, Fumiaki Suzuki, Yoshihiro Suzuki, Atsushi Nakamura, Internet conference 2003 memoir, pp 5 to 10, October 2003.